-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mkShellMinimal: Create an ultra minimal nix-shell #132617
base: master
Are you sure you want to change the base?
Conversation
e251480
to
42ce8dd
Compare
8c9ce8e
to
9001dc0
Compare
There is a section for special builders in nixpkgs doc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the goal? If to be minimal is there a path to use busybox instead of bash?
4900f19
to
7bc58d0
Compare
In practice I found we were using nix-shell to have a reproducible environment, but stdenv was bringing and doing a lot of stuff. I just wanted the ability to declare environment variables & a list of packages. I want to showcase an ultra-minimal mkShell (in fact the real mkShell should probably be built on-top of this), where one lists only a set of packages. The whole notion of |
591435f
to
b6ac56e
Compare
I will work on documentation once I get a few more 👀 on this. I have a few TODOS I added to the description that I still need to solve (if you have hints please share). |
@fzakaria thanks for working on this! @tomberek a more minimal shell would be good for packages that don't need the full closure of |
|
||
for a in $packages; do | ||
export PATH=$a/bin:$PATH | ||
done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It comes at a very very little cost, but does enable shell completions.
If that's not the design choice you want to make, I wonder if it should even set PATH. Maybe someone only wants to set another environment variable, in which case PATH is redundant.
I guess it boils down to the question "when is it not a shell anymore?" which is obviously not clearly delineated, but needs an answer for this to be actually minimal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, in what regard is it minimal? I would define it as the combination of the number of store paths and the total byte size. The latter is generally so disproportionally determined by dependencies that the size of the shellHook (or similar) does not matter, as long as it doesn't increase store path count.
I do consider store path count separately because it introduces latency with nix-copy-closure and most binary caches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say minimal with regards to closure size but from that we could support features to make the whole thing practical usable i.e. set MANPATH
.
builder = writeScript "builder.sh" '' | ||
#!${bash}/bin/bash | ||
echo | ||
echo "This derivation is not meant to be built, aborting"; | ||
echo | ||
exit 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@infinisil I actually don't see a particular reason why nix-shells can't be buildable.
I wonder if doing your export trick here to $out is enough + adding an error message.
@siraben since there's no dependency on coreutils (merely bash); I like that this in spirit allows the user to choose busybos or coreutils. I think keeping the sole dependency to bash more in spirit to this minimalism otherwise the choice will no longer be possible? |
Please don't use |
@roberth makes sense. |
The user should choose their own bash implementation if they don't want to use the impure PATH's bash, so optimizing it is another topic. Did you mean to use |
@roberth i did mean it for the builder since the expectation is that it's run on a POSIX compliant machine and for the purpose of having a development environment. |
Woot! ❯ nix path-info -rSsh $(nix-build -I nixpkgs=/home/fmzakari/code/github.com/NixOS/nixpkgs test-shell-local.nix)
these derivations will be built:
/nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv
/nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv
building '/nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv'...
building '/nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv'...
This derivation is not meant to be built, unless you want to capture the dependency closure.
/nix/store/8ka1hnlf06z3h2rpd00b4d9w5yxh0n39-setup 376.0 376.0
/nix/store/nprykggfqhdkn4r5lxxknjvlqc4qm1yl-builder.sh 280.0 280.0
/nix/store/xd8d72ccrxhaz3sxlmiqjnn1z0zwfhm8-my-test-shell 744.0 1.4K |
6da01e0
to
2931a05
Compare
Do you also plan to support |
I'd love to collaborate to continue to make this composable. Didn't get a chance to chat more with @zimbatm more about it. |
I'd like to see this included in nixpkgs. |
Co-authored-by: Sandro <[email protected]>
@fzakaria are you still planning on working on this? I would be interested in seeing it land in nixpkgs. |
I'm increasingly convinced that development shells should be started through It's a technically and organizationally superior solution, but the hacky |
@roberth do I understand correctly that your |
My concern is that this PR uses the wrong tool to achieve its goal, as |
I'm not sure how to make sense of these thoughts given that I use |
Roughly:
|
The discussion and PR i would like to continue to push forward is breaking down @roberth I don’t think anything in Thoughts? |
My only concern is that it may not achieve its end goal, but that doesn't mean that it doesn't have value. As I said, I won't oppose incremental changes like this PR.
This is a good goal, but you'll be duplicating significant parts of "stdenv". We already have a NixOS way of configuring the environment and a stdenv/setup/mkDerivation way of configuring environments. Will this create a third way of doing things? Perhaps a better angle for implementing this is to modularize stdenv. We have By using those minimal envs, you can modularize shells using the same functionality that is used for builds, such as the setup hooks, and you don't have to introduce a third way of doing things. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation suggestions.
with nixpkgs; | ||
mkShellMinimal { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove this super-broad use of with
from the doc? It doesn't seem to add anything over
with nixpkgs; | |
mkShellMinimal { | |
pkgs.mkShellMinimal { |
|
||
```nix | ||
let | ||
nixpkgs = import <nixpkgs> { }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nixpkgs = import <nixpkgs> { }; | |
pkgs = import <nixpkgs> { }; |
Since you use pkgs.mkShellMinimal
above (and is more idiomatic IMO)
I see a long term goal of rebuilding stdenv or stdenvNoCC using a new
modular format.
Right now it's subtractive rather than additive which makes it difficult to
think through.
…On Tue, Mar 8, 2022, 1:26 AM Robert Hensing ***@***.***> wrote:
@roberth <https://github.com/roberth> I don’t think anything in
mkMinimalShell goes against what you are saying.
My only concern is that it may not achieve its end goal, but that doesn't
mean that it doesn't have value. As I said, I won't oppose incremental
changes like this PR.
barest (smallest) unit first to start and everything else should compose
on top of it.
This is a good goal, but you'll be duplicating significant parts of
"stdenv". We already have a NixOS way of configuring the environment and a
stdenv/setup/mkDerivation way of configuring environments. Will this create
a third way of doing things?
Perhaps a better angle for implementing this is to modularize stdenv. We
have stdenvNoCC which, as the name suggests, does not include the C
compiler. Similarly, you could define more minimal "env"s. I'd stay away
from negations like "NoCC" and construct ones that are minimal with respect
to some goal. Maybe you could have setupenv which relies on an impure
environment, but runs setup.sh; shenv which builds on that but makes the
shell pure; unixenv which adds a small number of programs used in
scripts; busyboxenv, etc.
This feels like bootstrapping, but I don't know if these
distinctions/layers are useful for that. As far as I'm concerned, these
envs' dependencies should all be built with the usual stdenv, to keep
things simple.
By using those minimal envs, you can modularize shells using the same
functionality that is used for builds, such as the setup hooks, and you
don't have to introduce a third way of doing things.
—
Reply to this email directly, view it on GitHub
<#132617 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAETXDTCPV7SR57ISBXSKH3U64MOFANCNFSM5BQG55SA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@asymmetric Are you still requesting changes? I'd like @fzakaria to be able to merge this, if possible. |
@johnrichardrinehart I don't think my review is the main thing blocking this (but @fzakaria please do let me know if that's the case). There are conflicts that must be resolved. But on the topic of my review: I especially think we shouldn't advocate the "global" |
A truly minimal shell would not have the form of a derivation, however this requires changes in the Nix CLI. |
Reverts commit d16d129. This did not work since many depend on stdenv. References: - NixOS/nixpkgs#132617 - NixOS/nixpkgs#116274
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/make-shell-a-modular-replacement-for-mkshell/48509/12 |
Motivation for this change
This shell is inspired some investigation I did
and a follow-up example that demonstrated starting a nix-shell with a minimal builder.sh.
The goal is to provide the facility to create an ultra-lightweight nix-shell that only has bash as the direct dependency. Users can set environment variables and add packages but the feature-set is purposely minimal.
This minimal nix-shell has effectively a 0 (1.4 KiB) size closure.
Things TODO
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)